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PRELIMINARY AMENDMENT 

Assistant Commissioner for Patents 
Washington, D.C. 20231 

Sir: 

Prior to examination and the calculation of filing fees, kindly amend the above- 
identified application as follows: 



IN THE SPECIFICATION : 

Page 1, immediately following the title, insert the following: 

-This disclosure is based upon, and claims priority from French Patent Application 
No. 98/01008, filed January 29, 1998, and International Application No. 
PCT/FR99/00096, filed January 20, 1999, the contents of which are incorporated herein by 
reference. 

Background of the Invention —. 
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Page 3, before line 1, insert the following heading: 
- Summary of the Invention --. 

Page 4, before line 1, insert the heading: 
- Brief Description of the Drawing - ; 

between lines 17 and 18, insert the heading: 
— Detailed Description — . 

IN THE CLAIMS : 

1 . (Amended) A system of managing the security of data processing 
applications, [characterised in that] comprising : 

[-] directory files in which the data processing applications are stored, said 
[recorded in] directory files [(Repl, Rep2, Rep31, Rep32, Rep41, Rep42, Rep51, Rep52)] 
being organised in an n-level tree, the level 1 directory [(Repl)] being the highest level ; 
and 

[-] a number [r] of security registers [(R)] which can each be allocated to a single 
directory [and],,, each security register [(R)] containing all the rights or secrets [SI to Sp] 
which have been granted under a directory. 

2. (Amended) A method of managing the security of data processing 
applications [in a system according to Claim 1, characterised in that it comprises the 
following steps consisting] , comprising the steps of : 
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(a) storing in security registers [(R)] the rights [(SI to Sp)] granted under a 
directory [(Rep)] according to given rules [(RG1 , RG2, RG3)]; 

(b) seeking [in the tree] the secrets presented in an n-level tree of directory files 
in which data processing applications are stored ; and 

(c) verifying the knowledge of one or more rights at the level of the data 
processing application. 

3. (Amended) A method according to Claim 2, [characterised in that] wherein 
the storage rules of step (a) are as follows : 

[(RGI) :] allocation of a security register [(R)] to [the] a current directory as soon 
as a right has been granted under this directory or [the] said security register has been 
updated if a right has already been granted under this directory ; 

[(RG2)] loss of the link connecting the old current directory to its security register 
when a new directory is selected except if the selected directory is the child of the old 
current directory; and 

[(RG3)] allocating the security register that was allocated the earliest to the new 
current directory if the security registers are all allocated. 

4. (Amended) A method according to Claim 2 [or 3, characterised in that] 
wherein step (b) consists of applying the following rule [consisting of] : 

[(RG4)] verifying that the secret presented [(S)] is known in the current directory 
(Ni) or in a directory at a higher level. 
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5. (Amended) A method according to Claim 2, [3 or 4, characterised in that] 
wherein step (b) comprises the following intermediate steps [consisting of] : 

(bl) seeking a secret in the current directory at level (Ni) and verifying the 
existence of the secret [(S)] within the application ; 

(b2) if [this] said secret [(S)] exists, verifying that the presentation of the secret 
has succeeded ; 

if the presentation has succeeded, the right associated with the secret [(S)] is 
granted at the level (Ni) of the current application ; 

if the presentation has failed, the right associated with the secret [(S)] is not 
granted and the attempted presentation is terminated ; 

(b3) if [this] said secret [(S)] does not exist within the current application at level 
(Ni) , seeking whether this secret [(S)] exists within the parent application at level N(i-l) ; 

(M) if [this] said secret [(S)] exists in the parent application at level [B]N(i-l), 
verifying that the presentation has succeeded ; 

if the presentation has succeeded, the right associated with the secret [(S)] is 
granted in the current application at level (Ni) ; 

if the presentation has failed, the right associated with the secret [(S)] is not 
granted and the attempted presentation is terminated ; 

(b5) if the secret does not exist within the parent application at level N(i-l), 
seeking the existence of the secret [(S)] at the level of the application at level N(i-2) along 
the hierarchical axis and verifying that the presentation has succeeded ; 
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and so on as far as the highest hierarchical level as long as the existence of the 
secret [(S)] has not been discovered ; 

(b6) if the secret [(S)] has not been discovered, the attempted presentation is 
terminated. 

6. (Amended) A method according to [one of the preceding Claims 2 to 5, 
characterised in that] claim 2. wherein the step (c) consists of applying the following rule 
[consisting of] : 

[(RG5)] authorisation of a function requiring knowledge of a secret [(S)] if and 
only if, running through the tree along the hierarchical axis from the current application to 
the root application, the first secret [(S)] is known to at least one of the applications 
belonging to the tree section for which the current application and the application 
containing the secret [(S)] are delimiters. 

7. (Amended) A method according to [one of the preceding Claims 1 to 6, 
characterised in that] claim 2. wherein step (c) comprises the following steps [consisting 
of]: 

(cl) verifying that a security register is associated with the current application at 
level Ni ; 

(c2) authorising the function if the security register contains the required right 
and terminating the verification ; 
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(clO) refusing the function and terminating the verification if the secret has not 
been discovered. 

REMARKS 

Entry of the foregoing amendments is respectfully requested. These amendments 
are intended to further clarify the language of the claims and specification. 



Respectfully submitted, 




Burns, Doane, Swecker & Mathis, L.L.P. 



James A. LaBarre 
Registration No. 28,632 



P.O. Box 1404 

Alexandria, Virginia 22313-1404 
(703) 836-6620 



Date: July 28, 2000 
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VERIFIED TRANSLATION OF INTERNATIONAL APPLICATION 



I, Michele Ruby Gouze residing at 32 rue Arago, 92800 Puteaux, France, hereby 
certify that I am conversant with the French language and I am a competent 
translator thereof into the English language, and that to the best of my knowledge 
and belief, the following is a true and correct translation of the specification and 
claims as originally filed in respect of the International patent application 
PCT/FR99/00096 of the 20 th January 1999. 



Signed this 1 8 th day of July 2000 
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AND M ETH0D_F0R_MANA6ING COMPUTER APPLICATIONS 
SECURITY— 

The invention concerns data processing systems and 
5 more particularly, in such systems, a system and method 
for managing the conditions for access to the different 
applications which are liable to be implemented by these 
data processing systems. The invention is preferentially 
but not limitatively intended to be implemented in the 
10 microprocessors of smart cards, whatever the field of 
use : health, banking, transport, mobile telephones etc. 

The known security management methods have the 
following principal drawbacks : 

- the first drawback is an obligation to have a 
15 hierarchy for selecting an application, that is to say 
it is necessary to pass through an imposed selection 
path commencing with the "grandparent" application and 
then the "parent" application in order to arrive at the 
"child" application, that is to say a selection path 



similar to the one for selecting a file in a directory 
on a hard disk; in addition, no provision is made with 
regard to security. 

There is therefore no relationship between the 
5 selection level and the security level. 

- The second drawback is limiting the number of 
security levels or the number of applications. This is 
because a security register is dedicated to each 
application, the said register storing the rights 

10 acquired by this application through knowledge of 
secrets. In order to add n levels, that is to say to 
have a multiapplication series, it is necessary to 
associate, for example, a security register with each 
application, which results in using a large part of the 

15 high-speed memory where the security registers are 
stored. As the capacity of this high-speed memory is 
limited, it is not desirable to store many security 
registers therein. Thus, in certain systems, the number 
of hierarchical levels or the number of applications has 

20 been limited to three, that is to say three security 
registers . 

The third drawback is preventing the simple 
"emancipation" of the applications, that is to say 
making a "child" application independent of its "parent" 
25 application. This is because, when a new application is 
created, it is essential to use the rights and secrets 
of the "parent" application, which are the only ones 
available, until the secrets peculiar to the "child" 
application are created. 



3 



The aim of the present invention is to implement a 
method of managing the security of data processing 
applications which does not have the drawbacks disclosed 
above and which therefore makes it possible : 
5 - not to be limited with regard to the number of 

hierarchical levels or number of applications, and ; 

- to make a "child" application independent of the 
"parent" application without passing through the latter 
from the security point of view. 

10 The invention therefore concerns a system of 

managing the security of data processing applications, 
characterised in that : 

- the data processing applications are recorded in 
directory files organised in an n-level tree, the level 

15 1 directory being the highest level, and ; 

- a number r of security registers which can each 
be allocated to a single directory and each security 
register containing all the rights or secrets SI to Sp 
which have been granted under a directory. 

20 The invention also concerns a method of managing 

the security of data processing applications in the 
management system described above, characterised in that 
it comprises the following steps consisting of : 

(a) storing in security registers the rights 
25 granted under a directory according to given rules ; 

(b) seeking in the tree the secrets presented, and 

(c) verifying the knowledge equivalent to one or 
more rights at the level of the data processing 
application in order to satisfy the access conditions. 



Other characteristics and advantages of the 
present invention will emerge from a reading of the 
following description of particular example embodiments, 
the said description being given in relation to the 
5 accompanying drawings, in which : 

Figure 1 is an example of a directory tree 
structure ; 

- Figures 2.1 to 2.14 illustrate examples of the 
application of three rules for the allocation or 

10 deallocation of a security register to or from a 
directory ; 

- Figures 3.1a to 3.6a and 3.1b to 3.6b illustrate 
examples of the application of the rule for the 
presentation of a secret ; and 

15 - Figures 4.1 to 4.6 illustrate examples of the 

application of the rule for verifying the granting of 
the required right. 

The invention will be described in its application 
to a smart card and, more precisely, to a microprocessor 

20 used in a smart card. However, it is also applicable to 
any data processing system where it is necessary or 
simply desirable for certain services or functions 
offered by the system to be accessible only to certain 
users or operators . 

25 In the case of smart cards, for example a bank 

card or a mobile telephone card, the services or 
functions which are available to the user may be subject 
to authorisation according to the type of subscription 
taken out, these authorisations (or rights) being 

30 granted by proving the knowledge of secrets which allow 
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access to the files necessary for the use of the service 
or function. 

In the remainder of the description, the following 
definitions will be adopted : 
5 - A file is a set of data able to be protected by 

access conditions ; 

- A directory Rep is a set of files and/or 
directories in accordance with an arborescent 
organisation (Figure 1); normally a directory is 

10 dedicated solely to one application ; 

- The conditions for access to a file or directory 
Rep define the criteria to be fulfilled, such as the 
presentation of a secret code or an external 
authentication, in order to be able to effect such or 

15 such a function on the file or directory ; 

- The files and directories are organised in a 
tree with several levels, where the highest-level 
directory (level 1) is referred to as the "root" 
directory, or root of the tree. A level characterises 

20 the directories having the same hierarchical degree. 

The use of directories makes it possible to structure 
the data in a smart card. In Figure 1, only the 
directories Repl, Rep2, Rep31, Rep32, Rep41, Rep42, 
Rep51 and Rep52 have been presented and each can contain 

25 one or more files. The directory Repl is the root of 
the tree comprising n=5 levels of directories, the 
directories Rep41 and Rep42 belonging to the level i=4 ; 

- A security register R contains all the rights 
which have been granted under a directory and a right is 

30 the proof of the knowledge of a secret which is 



identified by a reference such as a name, a number or an 
identifier. There are several ways of proving knowledge 
of a secret, for example by exchanging the value of the 
secret between the terminal and smart card or by 
exchanging data calculated by means of this secret: the 
operation is called presentation of the secret. 

In general terms, the foundation of security on a 
smart card is to be able to make the use of the service 
or the function of the smart card dependent on proof of 
the knowledge of one or more secrets. Thus, in order to 
be able to use a function of the card, it is necessary : 

- for the smart card to previously store this 
proof of the knowledge of the secret or secrets in a 
security register ; 

- for the bearer of the smart card or terminal to 
prove that he has knowledge of the secret or secrets 
protecting the function ; 

- for the card to verify, when the function is 
used, that the secret or secrets are indeed known. 

The invention lies in the steps of the method 
consisting of : 

(a) storing in the smart card the knowledge of the 
secret or secrets, that is to say the rights granted, 
according to the rules of allocation and deallocation of 
a security register to a directory ; 

(b) seeking in the tree the secret or secrets 
presented ; 

(c) verifying the knowledge of the secret or 
secrets in order to fulfil the access conditions. 
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To store the knowledge of a secret in a smart card 
(step (a)), it is necessary to correctly present the 
secret, which amounts to proving that the outside, for 
example a terminal or a card carrier, has knowledge of 
the said secret, this knowledge conferring on it or him 
the right to use functions or services offered by the 
card. It is the right which is stored in a security 
register at the rate of one register per application. 

A security register R comprises a number p of 
digits or positions, each position being allocated to 
the knowledge of a secret corresponding to a granted 
right. A register with p=8 positions can record the 
knowledge of eight secrets SI to S8, which will 
correspond to eight rights granted. 

The number r of security registers R can be any 
number and the example which will be described will 
include r=3 of them. The security registers are not 
dedicated to a given level or directory as in the prior 
art and the link between a directory and a security 
register is dynamic, that is to say this link can be 
created or broken in accordance with the rules of the 
method according to the invention. 

In order to store a right in a directory, it is 
necessary first of all to allocate or deallocate a 
security register to or from a directory in accordance 
with the following three rules RG1 to RG3 : 

Rule RG1 : 

A register is allocated to the current directory 
as soon as a right is granted under this directory, for 
example a secret code or an authentication. If a right 



has already been granted under this directory, the 
register dedicated to it is updated. 
Rule RG2 : 

Selection of a new directory gives rise to the 
loss of the link connecting the old current directory to 
its security register except if the directory selected 
is the "child" of the old current directory. 

Rule RG3 : 

If the number r of security registers is 
saturated, that is to say the R=3 in the example 
described are used, the register which was allocated 
first, that is to say the highest level in the tree, is 
allocated to the new current directory in accordance 
with rule RG1 . 

It should be noted that the application of rule 
RG2 makes it possible to allocate two security registers 
to the same level, so that the allocation of a security 
register to a directory may be represented by a 
hierarchical level Ni allocated to the security register 
concerned, i varying from 1 to n. 

Figures 2.1 to 2.14 illustrate applications of the 
rules RG1, RG2 and RG3 . In these figures and the others, 
a black circle designates a directory, a grey circle 
designates a selected directory and a white circle 
designates a selected directory with a right removed. 

Figure 2.1 illustrates the absence of selection of 
a directory whilst Figures 2.2 and 2.3 illustrate 
respectively the selection of the directories Repl and 
Rep2 . 
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Thus the application of rule RG1 is illustrated in 
Figures 2.4, 2.6, 2.8, 2.10, 2.12 and 2.14. Figure 2.4 
illustrates the presentation of a secret under the 
directory Rep2 at level N2 . Figure 2.6 illustrates the 
5 presentation of a secret under the directory Rep31 at 
level N3. Figure 2.8 illustrates the presentation of a 
right under the directory Rep41 at level N4 . Figure 2.10 
illustrates the presentation of a right under the 
directory Rep51 at level N5 . Figure 2.12 illustrates the 

10 presentation of a right under the directory Rep41. 

Figure 2.14 illustrates the presentation of a right 
under the directory Rep42. 

The application of rule RG2 is illustrated by 
Figures 2.5, 2.7 and 2.9 with regard to the maintenance 

15 of the link between a security register and its 
directory when a new "child" directory thereof is 
selected . 

Figures 2.5, 2.7 and 2.9 illustrate respectively 
the selection of the directory Rep31, Rep41 or Rep51. 

20 The application of rule RG2 is illustrated by 

Figures 2.11 and 2.13 with regard to the breaking of the 
link between a security register and its directory. Thus 
Figure 2.11 illustrates the selection of the directory 
Rep41 whilst Figure 2.13 illustrates the selection of 

25 the directory Rep42. 

The application of rule RG3 is illustrated by 
Figure 2.10, in which the register allocated the 
earliest Rl is allocated to the new selected directory 
Rep51 . 



Step (a) consisting of storing the rights attached 
to the knowledge of the secrets being performed, step 
(b) consisting of seeking in the tree the secret 
presented by the bearer of the smart card or by the 
5 terminal can be implemented. 

A secret presented at the level of an application 
confers a right of use at the level of this same 
application. Thus the successful presentation of a 
secret within an application with the hierarchical level 
10 Ni updates the security register dedicated to this 
hierarchical level, in accordance with rule RG1, even if 
the secret presented is physically situated in a higher 
hierarchical level. 

The rule for presentation of a secret is as 
15 follows : 

Rule RG4 : 

The presentation of a reference secret S amounts 
to verifying that the bearer of the smart card or 
terminal knows the value of the first reference secret S 
20 found by running through the hierarchical axis of the 
current application to the root directory. 

The presentation of the reference secret S at the 
level of the current application situated at the 
hierarchical level Ni is effected by means of the 
25 following intermediate steps consisting of : 

(bl) seeking a reference secret S in the current 
directory, that is to say at the level Ni, by means of a 
security management system, and verifying the existence 
of this secret within the application ; 
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(b2) if this secret exists, verifying that the 
presentation of the secret has succeeded, for example 
value for a secret code, cryptogram for a key, etc. 

If the presentation has succeeded, the right 
5 associated with reference secret S is granted at the 
level of the current application at level Ni . 

If the presentation has failed, the right 
associated with the reference secret S is not granted 
and the attempted presentation is terminated. 
1° (b3) If the reference secret S does not exist 

within the current" application at level Ni, seeking 
whether a secret with the same reference exists within 
the parent application at a level N(i-l) of the current 
application . 

15 (b4) If the secret exists at the level of the 

parent application at level N(i-l), verifying that the 
presentation has succeeded. 

If the presentation has succeeded, the right 
associated with the reference secret S is granted at the 
20 level of the current application at level Ni. 

If the presentation has failed, the right 
associated with the reference secret S is not granted 
and the attempted presentation is terminated. 

(b5) If the reference secret S does not exist 
25 within the parent application at level N(i-l), seeking 
the reference secret S at level N(i-2) along the 
hierarchical axis, and so on as long as the existence of 
a reference secret S has not been discovered. 

(b6) If the reference secret S has not been found, 
30 the attempted presentation is terminated. 



Several examples of the application of rule RG4 
are illustrated in Figures 3.1a to 3.6a and 3.1b to 
3.6b. Figures 3.1a and 3.1b, 3.2a and 3.2b, 3.3a and 
3.3b correspond to examples where the right is granted 
5 whilst Figures 3.4a and 3.4b, 3.5a and 3.5b, 3.6a and 
3.6b correspond to examples where the right is not 
granted . 

In Figure 3.1a, the secret S3 exists locally under 
the directory Rep41 and no register is allocated to the 

10 directory Rep41. In Figure 3.1b, knowledge of the secret 
S3 is proved; a register R3 is allocated to the 
directory Rep41 at level N4 and the right is granted. 

In Figure 3.2a, the secret S3 exists locally under 
the directory Rep41 and a register R3 is already 

15 allocated to the directory Rep41. Knowledge of the 
secret S3 is therefore proved and the security register 
R3 allocated to the directory Rep41 is updated (S3) so 
that the right is granted (Figure 3.2b). 

In Figure 3.3a, the secret S2 does not exist 

20 locally under the directory Rep41; a register R3 is 
already allocated to the directory Rep41 and a secret S2 
exists at the same time under the directories Rep2, 
Repl, Rep42 and Rep51. Knowledge of the secret S2 is 
therefore proved and the security register allocated to 

25 the directory Rep41 is updated so that the right is 
granted (Figure 3.3b). 

In Figure 3.4a, the secret S2 does not exist 
locally under the directory Rep41; a register R3 is 
already allocated to the directory Rep41 and a secret S2 

30 exists both under the directories Rep2, Repl, Rep42 and 



13 



Rep51. Knowledge of the secret S2 is therefore not 
proved so that the security register R3 allocated to the 
directory Rep41 is not updated and the right is not 
granted (Figure 3.4b). 

In Figure 3.5a, the secret S2 does not exist 
locally under the directory Rep41; a register R3 is 
already allocated to the directory Rep41 and a secret S2 
exists at the same time under the directories Rep2 , 
Repl, Rep42 and Rep51. Knowledge of the secret S2 is 
therefore not approved so that the security register R3 
allocated to the directory Rep41 is not updated and the 
right is not granted (Figure 3.5b). 

In Figure 3.6a, the secret S2 does not exist 
locally under the directory Rep 41; a register R3 is 
already allocated to the directory Rep41 and a secret S2 
exists at the same time under the directories Rep2, 
Repl, Rep42 and Rep51. Knowledge of the secret S2 is not 
proved so that the security register R3 allocated to the 
directory Rep41 is not updated and the right is not 
granted (Figure 3.6b). 

Step (c) consists of verifying that knowledge of 
the secret or secrets for fulfilling the access 
conditions, that is to say verifying that the secret 
protecting use of a function and service of the smart 
card, is indeed known to the outside world, that is to 
say that the right required has indeed been granted. 

To this end, the invention implements a fifth rule 
RG5 which is stated as follows: 

Rule RG5 : 



A function requiring knowledge of a secret S is 
authorised if and only if, running through the tree 
along the hierarchical axis of the current application 
towards the root application, the first secret S 
encountered is known, that is to say correctly 
presented, by at least one of the applications belonging 
to the tree section having the current application and 
the application containing the secret S as its 
delimiters, these applications being able to be merged 
if the secret S exists in the current application. 

In order to perform step (c) , the management 
system must perform the following steps consisting of : 

(cl) verifying that a security register is 
associated with the current application at level Ni ; 

(c2) authorising the function if the security 
register contains the required right and terminating the 
verification ; 

(c3) seeking the existence of the reference secret 
S within the current application at level Ni if no 
security register is associated with the current 
application or if the associated register does not 
contain the required right ; 

(c4) refusing the function and terminating the 
verification if the secret exists within the current 
application ; 

(c5) verifying that a security register is 
associated with the parent application at level N(i-l) 
of the current application if the reference secret S 
does not exist within the current application at level 
Ni ; 
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(c6) authorising the function and terminating the 
verification if the security register associated with 
the parent application contains the right required for 
using the function ; 
5 (c7) seeking the existence of the reference secret 

S within the parent application at level N(i-l) of the 
current application if no security register is 
associated with the parent application or if the 
associated security register does not contain the 
10 required right ; 

(c8) refusing the function and terminating the 
verification if the reference secret S exists within the 
parent application at level N(i-l) ; 

(c9) verifying that a security register is 
15 associated with the grandparent application at level 
N(i-2) of the current application along the hierarchical 
axis of the current application towards the root 
application, if the reference secret S does not exist 
within the parent application at level N(i-l), 
20 and so on as long as the existence of the 

reference secret S has not been discovered ; 

(clO) refusing the function and terminating the 
verification if the secret has not been discovered. 

Figures 4.1 and 4.2 illustrate two examples of an 
25 authorised function whilst Figures 4.3, 4.4, 4.5 and 4.6 
illustrate four examples of a refused function. 

In Figure 4.1, the function is accepted since the 
secret S3 exists locally, and is known under the 
directory Rep41. 



In Figure 4.2, the function is accepted since the 
secret SI does not exist locally but is known under the 
directory Rep2 . 

In Figure 4.3, the function is rejected since the 
secret S3 exists locally under the directory Rep41 and 
no right has been granted under this directory. 

In Figure 4.4, the function is rejected since the 
secret S3 exists locally under the directory Rep41 and, 
although a security register R3 is allocated to the 
directory Rep41, knowledge of the secret S3 has not been 
proved . 

In Figure 4.5, the function is rejected since the 
secret S2, which does not exist locally under the 
directory Rep41, nor in the directory Rep31, exists 
under the directory Rep2 and no security register is 
allocated to the directory Rep2 . It should be noted 
that the function is rejected although a secret S2 is 
known under the directory Repl . 

In Figure 4.6, the function is rejected since the 
secret SI has not been found by running along the 
hierarchical axis from the directory Rep41 towards the 
directory Repl, although a secret SI exists under the 
directories Rep51 and Rep32 . 



17 



CLAIMS 

1. A system of managing the security of data 
processing applications, characterised in that : 

- the data processing applications are recorded in 
directory files (Repl, Rep2, Rep31, Rep32, Rep41, Rep42, 
Rep51, Rep52) organised in an n-level tree, the level 1 
directory (Repl) being the highest level ; and 

- a number r of security registers (R) which can 
each be allocated to a single directory and each 
security register (R) containing all the rights or 
secrets SI to Sp which have been granted under a 
directory . 

2 . A method of managing the security of data 
processing applications in a system according to Claim 
1, characterised in that it comprises the following 
steps consisting of : 

(a) storing in security registers (R) the rights 
(SI to Sp) granted under a directory (Rep) according to 
given rules (RG1, RG2 , RG3) ; 

(b) seeking in the tree the secrets presented ; 

and 

(c) verifying the knowledge of one or more rights 
at the level of the data processing application. 

3. A method according to Claim 2, characterised in 
that the storage rules of step (a) are as follows : 

(RG1) : allocation of a security register (R) to 
the current directory as soon as a right has been 
granted under this directory or the said security 



register has been updated if a right has already been 
granted under this directory ; 

(RG2) loss of the link connecting the old current 
directory to its security register when a new directory 
is selected except if the selected directory is the 
child of the old current directory ; 

(RG3) allocating the security register allocated 
the earliest to the new current directory if the 
security registers are all allocated. 

4. A method according to Claim 2 or 3, 
characterised in that step (b) consists of applying the 
following rule consisting of : 

(RG4) verifying that the secret presented (S) is 
known in the current directory (Ni) or in a directory at 
a higher level. 

5. A method according to Claim 2, 3 or 4, 
characterised in that step (b) comprises the following 
intermediate steps consisting of : 

(bl) seeking a secret in the current directory at 
level (Ni) and verifying the existence of the secret (S) 
within the application ; 

(b2) if this secret (S) exists, verifying that the 
presentation of the secret has succeeded ; 

if the presentation has succeeded, the right 
associated with the secret (S) is granted at the level 
(Ni) of the current application ; 

if the presentation has failed, the right 
associated with the secret (S) is not granted and the 
attempted presentation is terminated ; 
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(b3) if this secret (S) does not exist within the 
current application at level (Ni), seeking whether this 
secret (S) exists within the parent application at level 
N(i-l) ; 

5 (b4) if this secret (S) exists in the parent 

application at level B(i-l), verifying that the 
presentation has succeeded ; 

if the presentation has succeeded, the right 
associated with the secret (S) is granted in the current 
10 application at level (Ni) ; 

if the presentation has failed, the right 
associated with the secret (S) is not granted and the 
attempted presentation is terminated ; 

(b5) if the secret does not exist within the 
15 parent application at level N(i-l), seeking the 
existence of the secret (S) at the level of the 
application at level N(i-2) along the hierarchical axis 
and verifying that the presentation has succeeded ; 

and so on as far as the highest hierarchical level 
20 as long as the existence of the secret (S) has not been 
discovered ; 

(b6) if the secret (S) has not been discovered, 
the attempted presentation is terminated. 

6. A method according to one of the preceding 
25 Claims 2 to 5, characterised in that the step (c) 
consists of applying the following rule consisting of : 

( RG5 ) authorisation of a function requiring 
knowledge of a secret (S) if and only if, running 
through the tree along the hierarchical axis from the 
30 current application to the root application, the first 



secret (S) is known to at least one of the applications 
belonging to the tree section for which the current 
application and the application containing the secret 
(S) are delimiters. 

7 . A method according to one of the preceding 
Claims 1 to 6, characterised in that step (c) comprises 
the following steps consisting of : 

(cl) verifying that a security register is 
associated with the current application at level Ni ; 

(c2) authorising the function if the security 
register contains the required right and terminating the 
verification ; 

(c3) seeking the existence of the reference secret 
S within the current application at level Ni if no 
security register is associated with the current 
application or if the associated register does not 
contain the required right ; 

(c4) refusing the function and terminating the 
verification if the secret exists within the current 
application ; 

(c5) verifying that a security register is 
associated with the parent application at level N(i-l) 
of the current application if the reference secret S 
does not exist within the current application at level 
Ni ; 

(c6) authorising the function and terminating the 
verification if the security register associated with 
the parent application contains the right required for 
using the function ; 
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(c7) seeking the existence of the reference secret 
S within the parent application at level N(i-l) of the 
current application if no security register is 
associated with the parent application or if the 
associated security register does not contain the 
required right ; 

(c8) refusing the function and terminating the 
verification if the reference secret S exists within the 
parent application at level N(i-l) ; 

(c9) verifying that a security register is 
associated with the grandparent application at level 
N(i-2) of the current application along the hierarchical 
axis of the current application towards the root 
application, if the reference secret S does not exist 
within the parent application at level N(i-l) ; 

and so on as long as the existence of the 
reference secret S has not been discovered ; 

(clO) refusing the function and terminating the 
verification if the secret has not been discovered. 



SYSTEM AND METHOD FOR MANAGING COMPUTER APPLICATIONS 
SECURITY 



ABSTRACT 

The invention concerns a system for managing 
computer applications security, characterised in that : 
The computer applications are recorded in directory 
files (Repl, Rep2, Rep31, Rep32, Rep41, Rep42, Rep51, 
Rep52) organised in a tree-like structure with n levels, 
level 1 directory (Repl) being the highest level ; a 
number r of security registers (R) being attributed each 
to one single directory and each security register (R) 
containing the set of rights or secrets SI to Sp which 
have been assigned under one directory. 
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